Method, System, And Data Structure For Providing A General Request/Response Messaging Protocol Using A Presence Protocol

ABSTRACT

A method and system are described for providing a general request/response protocol using a presence protocol. According to an exemplary embodiment, a method is described for using the presence protocol for receiving from a requesting entity a descriptor of a resource associated with a responding entity and a request related to the resource. The descriptor and the request are sent to the responding entity using the presence protocol. Using the presence protocol, a response is received from the responding entity replying to the request. The response is sent to the requesting entity using the presence protocol.

RELATED APPLICATIONS

The present application is a continuation of co-pending U.S. patentapplication Ser. No. 11/160,157, entitled “Method, System, and DataStructure for Providing a General Request/Response Messaging ProtocolUsing a Presence Protocol.” The present application is also related toco-pending U.S. patent application Ser. No. 11/118,882 entitled “Systemand Method for Utilizing a Presence Service to Advertize ActivityAvailability,” filed on Apr. 29, 2005, and assigned to the assignee ofthe present application. The present application is also related toco-pending U.S. patent application Ser. No. 11/096,764, entitled “Systemand Method for Utilizing a Presence Service to Facilitate Access to aService or Application Over a Network,” filed on Mar. 31, 2005, andassigned to the assignee of the present application. The presentapplication is also related to co-pending U.S. patent application Ser.No. 10/960,365, entitled “System and Method for Utilizing ContactInformation, Presence Information and Device Activity,” and co-pendingU.S. patent application Ser. No. 10/960,135, entitled “System and Methodfor Utilizing Contact Information, Presence Information and DeviceActivity,” both filed on Oct. 6, 2004, and both assigned to the assigneeof the present application. The present application is also related toco-pending U.S. patent application Ser. No. 10/900,558, entitled “Systemand Method for Providing and Utilizing Presence Information,” filed onJul. 28, 2004, and assigned to the assignee of the present application.The present application is also related to co-pending U.S. patentapplication Ser. No. 10/903,576, entitled “System and Method forHarmonizing Changes in User Activities, Device Capabilities and PresenceInformation,” filed on Jul. 30, 2004, and assigned to the assignee ofthe present application. Each of the above-cited related applications isincorporated here by reference in its entirety.

BACKGROUND

Determining whether a person or object is present and available forinteraction or use has been, and likely will remain, an everydayoccurrence in society. As technology has evolved, so too have the waysin which we can determine the presence of persons or objects to interactwith. For example, the explosive growth over the past two decades in theuse of computers and their internetworking via wide-area networks(WANs), such as the Internet, has led to the development and use ofpresence services. Presence services can be used to convey a user'spresence on a network to other network users based on user'sconnectivity to the network via a computing and/or communication device.Information describing users' presence on a network can be used byapplications and/or other services to provide what are referred to hereas “presence aware applications.”

One of today's more popular presence aware applications is instantmessaging (or IM). Popular IM applications include Yahoo's YAHOOMESSENGER, Microsoft's MSN MESSENGER, and America Online's AOL INSTANTMESSENGER (or AIM). IM applications use presence services to allow usersto determine whether other users (referred to by these applications as“friends” or “buddies”) are present on (e.g., connected to) a network.Presence services can also be used to determine a user's status (e.g.,available, not available, and the like) and a communication address forcommunicating with a user. The communication address can include both ameans of communicating with the user (e.g., via a telephone or email)and a corresponding contact address (e.g., a telephone number or emailaddress).

The architecture, models, and protocols associated with presenceservices in general are described in “Request for Comments” (or RFC)documents RFC 2778 to Day et al., titled “A Model for Presence andInstant Messaging” (February 2000), and RFC 2779 to Day et al., titled“Instant Messaging/Presence Protocol” (February 2000), each publishedand owned by the Internet Society. While the various presence aware IMapplications described above may use proprietary architectures andprotocols to implement their presence service components, each of theapplications use presence architectures and protocols that areconsistent with the presence model and protocols described in RFC 2778and RFC 2779 in terms of features and function.

The presence service model described in RFC 2778 describes two distinctusers of a presence service, referred to as presence “clients”. Thefirst of these clients, called a presentity (combining the terms“presence” and “entity”), provides presence information to be stored anddistributed throughout the presence service. Presence informationincludes the status of a user of the presence service and may includeadditional information used by the service. This additional informationcan include, for example, the communication means and contract addressof the user as described above. Presence information can be stored ormaintained in any form for use by the presence service, but typically isorganized into portions referred to as presence tuples. As will beunderstood by those skilled in the art, a tuple, in its broadest sense,is a data object containing one or more components. Thus, a presencetuple can include an identifier of a user and the user's status, contactaddress, or other information used by the presence service.

The second type of presence client is referred to as a “watcher”.Watchers receive presence information from the presence service. Thepresence model of RFC 2778 describes types of watchers, referred to as“subscribers” and “fetchers”. A subscriber requests notification fromthe presence service of a change in some presentity's presenceinformation. The presence service establishes a subscription on behalfof the subscriber to a presentity's presence information, such thatfuture changes in the presentity's presence information are “pushed” tothe subscriber. In contrast, the fetcher class of watchers requests (orfetches) the current value of some presentity's presence informationfrom the presence service. As such, the presence information can be saidto be “pulled” from the presence service to the presentity. A specialkind of fetcher, referred to as a “poller”, is defined in the model thatfetches information on a regular (or polling) basis.

The presence service can also manage, store, and distribute presenceinformation associated with watchers, as well as the watchers'activities in terms of the fetching or subscribing to the presenceinformation of other presence clients using the presence service. This“watcher information” can be distributed to other watchers by thepresence service using the same mechanisms that are available fordistributing the presence information of presentities. It will beunderstood that while the model describes the presentity and watcher asseparate entities, these entities can be combined functionally as asingle presence entity having the characteristics of both a presentityand a watcher. Accordingly, the phrase “presence entity” (in contrast tothe term “presentity”) or more simply the term “entity” with anappropriate modifier (e.g., responding, requesting, receiving, orsending) will be used throughout this document to describe any one orany combination of all of the presentity, watcher, subscriber, fetcher,or poller entities described above.

Users of the presence service are referred to in the presence modeldescribed in RFC 2778 as principals. Typically, a principal is a personor group that exists outside of the presence model, but can alsorepresent software or other resources capable of interacting with thepresence service. The model does not define the requirements orfunctionality of principals, but does state that two distinct principalsbe distinct, and two identical principals be identical. For purposes ofthis document, this strict interpretation of principals should not beadopted—that is, two distinct principals need not be distinct, and twoidentical principals need not be identical. For example, the 3rdGeneration Partnership Project (3GPP) has included standards forincorporating presence services into their Universal MobileTelecommunications System (UMTS) that define the use of “publicidentities” for users of the UMTS. A particular UMTS user may haveseveral public identities. Consequently, were such a public identity tobe construed as a principal, the public identity as a principal could beassociated with more than one presence client.

According to the general presence model described in RFC 2778, aprincipal can interact with the presence system through a presence useragent (PUA) or a watcher user agent (WUA). As in the case of thepresentity and watcher clients to which these user agents interact, thepresence and watcher user agents can be combined functionally as asingle user agent having both the characteristics of the presence andwatcher user agents. User agents can be implemented such that theirfunctionality exists within the presence service, external to thepresence service, or a combination or both internal and external to thepresence service.

Most presence aware applications, such as IM, use presence services onlyto determine an application user's presence, status, and communicationaddress. For example, IM applications do not use the presence serviceitself to deliver core application services and information, such as theinstant messages themselves, to their users. More specifically, IMapplications do not use the base presence protocol messages (orcommands) to exchange instant message information, but instead rely on aseparate and distinct instant message protocol (see, e.g., RFC 2778 andRFC 2779) to exchange this information.

Likewise, other presence aware applications and extensions to presenceservices would be expected to use new protocols to support theseapplications or extended services. For example, to create a presenceaware application capable of providing request/response services,developers would be expected to use a specific request/responseprotocol, separate from the presence protocol, to support therequest/response services. Examples of request/response protocolsinclude Hypertext Transfer Protocol (HTTP), used, for example, toexchange information between clients and servers over the Internet, andSimple Mail Transfer Protocol (SMTP) used for exchanging email messagesover a network.

Indeed, the standards track publications RFC 3920 to Saint-Andre, titled“Extensible Messaging and Presence Protocol (XMPP): Core” (October2004), and RFC 3921 to Saint-Andre, titled “Extensible Messaging andPresence Protocol (XMPP): Instant Messaging and Presence” (October2004), each published and owned by the Internet Society, envision theuse of separate protocols for supporting presence and request/responseservices. These publications describe a protocol for streamingExtensible Markup Language (XML) elements to exchange structuredinformation in close to real time between any two network endpoints.Rather than combining both presence information and request/responseinformation into a common XML stanza to be carried using only a presenceprotocol, XMPP defines the use of a first XML stanza (a “/presence”stanza) for carrying presence information and a separate, second XMLstanza (an “/iq” stanza) for carrying request/response information (see,e.g., RFC 3920; section 9). These separate stanzas would then be carriedby respective presence and request/response protocol layers.

Others have described arrangements for sending application informationusing a presence service, but fall short of providing generalrequest/response services using a presence protocol. For example, U.S.Patent Application No. 200410122896 A1 to Gourraud, titled “Transmissionof Application Information and Commands Using Presence Technology”,describes a presence entity that publishes application information orcommands destined to a certain application, in the form of a presencetuple. The watcher subscribes to presence information associated withthe certain application, and once authorized, receives the tuple withthe application information or command.

In a first embodiment, Gourraud's arrangement sends an applicationidentifier from user equipment to an application server using a presenceservice. The application server then sends predefined information to theuser equipment using the presence service. The arrangement does notallow the user equipment to request specific information or servicesfrom the application server—only the predefined information may bereceived. Indeed, no mechanism is described in Gourraud's firstembodiment for sending a request from the user equipment to theapplication through using the presence service or presence protocol. Ina second embodiment, Gourraud's arrangement allows a command to be sentfrom the user equipment to an application server using a presenceservice. Only an acknowledgment that the command was executed by theserver is sent to the user equipment. Moreover, the acknowledgment issent using a separate protocol from the presence protocol, i.e., aninstant message confirmation is sent using the Session InitiationProtocol (SIP). As such, no response is sent from the application serverto the user equipment in Gourraud's second embodiment, nor is anymechanism described in the embodiment for sending such a response usingthe presence service or presence protocol.

Rather than using multiple protocols to support a presence awareapplication that is capable of providing request/response services, itwould be more efficient and desirable to have an arrangement forproviding a general request/response messaging protocol using a presenceservice and its underlying presence protocol.

SUMMARY

Accordingly, a method and system are disclosed for providing a generalrequest/response protocol using a presence protocol. According to anexemplary embodiment, a method is described for using the presenceprotocol for receiving from a requesting entity a descriptor of aresource associated with the responding entity and a request related tothe resource; sending the descriptor and the request to the respondingentity; receiving a response from the responding entity replying to therequest message; and sending the response to the requesting entity.

According to another exemplary embodiment, a method is disclosed forproviding a general request/response protocol using a presence protocol.The method includes receiving via the presence server a descriptor of aresource and a request related to the resource; processing the requestby the resource to form a response replying to the request; and sendinga response to the presence server replying to the request message.

According to yet another an exemplary embodiment, a method is disclosedfor providing a general request/response protocol using a presenceprotocol. The method includes sending a descriptor of a resource and arequest related to the resource; and receiving via the presence server aresponse replying to the request message.

According to still another exemplary embodiment, a computer readablemedium is disclosed containing a data structure for use with a presenceprotocol in providing a general request/response protocol. The datastructure includes a resource data object including an element forstoring a descriptor of a resource associated with a responding entity;a request data object including an element for storing a request from arequesting entity related to the resource; and a response data objectincluding an element for storing a response from the responding entityreplying to the request message.

According to another exemplary embodiment, a system is described forproviding a general request/response protocol. The system includes apresence server configured to receive, store, and distribute informationusing a presence protocol. A responding device is configured to exchangeinformation with the presence server using the presence protocol. Theresponding device includes access to at least one resource; a respondingwatcher component configured to receive via the presence server adescriptor of a resource and a request related to the resource; and aresponding presentity component configured to send a response to thepresence server replying to the request message. The system alsoincludes a requesting device configured to exchange information with thepresence server using the presence protocol. The requesting deviceincludes a requesting presentity component configured to send thedescriptor and the request related to the resource to the presenceserver; and a requesting watcher component configured to receive via thepresence server the response replying to the request message.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings provide visual representations which will beused to more fully describe the representative embodiments disclosedhere and can be used by those skilled in the art to better understandthem and their inherent advantages. In these drawings, like referencenumerals identify corresponding elements, and:

FIG. 1 illustrates a system for providing a general request/responseprotocol using a presence protocol according to an exemplary embodiment.

FIG. 2 is a block diagram illustrating the various components that canform a responding and/or requesting network devices according to anexemplary embodiment.

FIG. 3 illustrates an interface that may be used by an owner of theresource to interact with responding and/or requesting entity accordingto an exemplary embodiment.

FIG. 4 illustrates a data structure for use with a presence protocol inproviding a general request/response protocol according to an exemplaryembodiment.

FIGS. 5A and 5B show an expanded view of a request data object includedin the data structure of FIG. 4 according to an exemplary embodiment.

FIG. 6 shows an expanded view of a response data object included in thedata structure of FIG. 4 according to an exemplary embodiment.

FIG. 7 depicts a data structure for storing presence informationassociated with an IM resource according to an exemplary embodiment.

FIG. 8 is a flowchart illustrating a method for providing a generalrequest/response protocol using a presence protocol according to anexemplary embodiment.

FIG. 9 illustrates an exemplary flow of information occurring amongpresence entities in carrying out a multi-entity transaction.

FIG. 10 is signal flow diagram for an illustrative request/responsescenario according to an exemplary embodiment.

DETAILED DESCRIPTION

Various aspects will now be described in connection with exemplaryembodiments, including certain aspects described in terms of sequencesof actions that can be performed by elements of a computer system. Forexample, it will be recognized that in each of the embodiments, thevarious actions can be performed by specialized circuits or circuitry(e.g., discrete and/or integrated logic gates interconnected to performa specialized function), by program instructions being executed by oneor more processors, or by a combination of both. Thus, the variousaspects can be embodied in many different forms, and all such forms arecontemplated to be within the scope of what is described.

When describing the architecture, models, and protocols associated withpresence services, this document uses terms described in RFC 2778 andRFC 2779. While the various presence service and presence protocolembodiments used today have differences, all of these embodiments usepresence architectures and protocols that are consistent with thepresence model and protocols described in RFC 2778 and RFC 2779 in termsof features and function. Accordingly, the terms used here should not belimited to any one of the presence models, services, and/or protocolembodiments in use today.

For example, today's presence protocols each support a common set ofmessages (or commands) from a functional standpoint (See, e.g., RFC2779). These functional commands include:

-   -   Publish: Allowing a presence entity (through a PUA/presentity)        to update/provide its own presence information (e.g. its status        or contact information) to a presence server;    -   Notify: Allowing a presence server to provide information from a        presence tuple to a WUA/watcher. Notifications may be        point-to-point (e.g., via a directed publish/notify command as        described in the following paragraph) or broadcast; and    -   Subscribe (Unsubscribe): Allowing a WUA/watcher to subscribe or        unsubscribe to notifications related to specific presence        information.        The phrase “presence protocol”, as used here, includes at least        those commands to allow entities to publish presence        information, notify entities of other entities' presence        information, and allow entities to subscribe (unsubscribe) to        other entities' presence information.

Several optional, functionally equivalent presence commands also exist.These optional commands include:

-   -   Probe: Allowing a presence service to get information associated        with a presence entity. This is equivalent to a combined        Notify/Publish command except that the presence service requests        presence information rather than having the presence client send        the information unsolicited; and    -   Directed Publish/Notify: Allowing a client to issue a publish        command that results in a notify command being sent to a        specific presence client, thus bypassing the subscription        function.

There is also a functional equivalent set of commands for managing a“friends list” (or “roster”) related to presence services. This set ofcommands includes:

-   -   Request: Allowing a client to request a specific or default        roster;    -   Add: Allowing a client to add an item for a presence entity to a        roster;    -   Update: Allowing a client to update a roster item; and    -   Delete: Allowing a client to delete an item from a roster.        Related to rosters are privacy lists. A privacy list can be        generally described in terms of a roster configured to identify        presence clients that are to be blocked from interacting with        the owner of the roster/privacy list.

Referring now to FIG. 1, a system 100 is depicted for providing ageneral request/response protocol using a presence protocol. The systemincludes a presence server 118 configured to receive, store, anddistribute information via a presence service 120. The system furtherincludes responding and requesting devices 102 configured to exchangeinformation with the presence server 118 via the network 116 using apresence protocol. The responding and requesting devices 102 can includeany of Personal Computers (PCs), Personal Digital Assistants (PDAs),network-enabled cameras, camera phones, cell phones, and the like.

Although depicted as a stand-alone server in FIG. 1, the presence server118 can include several servers (not shown) that together can functionas the presence service 120. Moreover, the function of the presenceserver 118 can be incorporated, either in whole or in part, into any ofthe devices 120 and server 118 shown in the figure, and thus can bedistributed throughout the network of elements shown. As such, themeaning of “presence server” used here does not strictly conform to thedefinition of a “server” included in RFC 2778 as being an indivisibleunit of a presence service. Nevertheless, the presence server 118 andpresence service 120 are closely link to one another and can beconsidered to perform one and the same function. As used here, however,the presence server 118 can also include additional services, such asthe account service 122 and proxy service 124 shown in FIG. 1, althoughthese additional services need not be included in the server 118. Itwill be understood that these additional services can also bedistributed across one or more servers or devices 102 interconnected viathe network 116.

A responding device can be, for example, a PC, such as the PC 102 bshown in FIG. 1. The responding device 102 b includes access to at leastone resource. The resource can be any service, application, file, orother information associated with the responding device that can be madeavailable for use by or interaction with a requesting device, such asthe camera 102 a or camera phone 102 c, via the network 116. Forexample, FIG. 1 shows that the responding device 102 b can provideresources including services 104 (e.g., web services, such as a photosharing website), software applications 108, and files 112 (such asimage files). Requesting devices, such as the camera 102 a or cameraphone 102 c, can request information or services related to theseresources using the presence service 120 via the network 116.

FIG. 2 is a block diagram illustrating the various components that canmake up the responding and/or requesting network devices 102. Forconvenience, the arrangement shown in FIG. 2 represents a network devicecapable of functioning both as a responding device and as a requestingdevice. Nevertheless, persons skilled in the art will understand that aresponding device need not include the components necessary to functionas a requesting device, and vice versa. Moreover, the figure includes aresponding/requesting presentity component 202 and responding/requestingwatcher component 204. It will be understood that each of thesecomponents can be combined into a single respective presentity 202 orwatcher 204 component, or can be implemented as separate responding andrequesting entities as described below.

First consider the arrangement of FIG. 2 from the perspective of aresponding device, such as the PC 102 b. From this perspective, thearrangement includes a responding presentity component 202. According toan exemplary embodiment, the responding presentity component 202 can beconfigured to send a descriptor of the resource 104, 108, 112 to thepresence server 118. The descriptor can include any information thatdescribes and/or identifies any of the resources 104, 108, 112 availableto the responding device, and can be used to advertise the availabilityof those resources to requesting devices for processing their requests.

For example, FIG. 2 shows that the responding device 102 b has access toweb services 104, including a photo sharing web service 104 a and otherweb services 104 b, a file system 112, printer services 104 c, andcamera services 104 d. The descriptor can simply identify a resource byname or can include other information to describe or identify theresource to other presence entities coupled to the network 116 Theresponding presentity component 202 can send the descriptor of theresource to the presence server 118 by including the descriptor inpresence information as described in conjunction with FIGS. 4-6 below.The presence information including the descriptor can be sent to thepresence server 118 via the presence protocol using a publish command.The descriptor can thus be used to advertise the availability of theresource to other presence entities that are subscribed to the presenceinformation of the responding device.

In an alternative embodiment, the responding presentity component 202need not send the descriptor of the resource 104, 108, 112 to thepresence server 118 to advertise the availability of the resource forprocessing requests. Instead, requesting devices coupled to the presenceserver 118 can broadcast a standardized request without a descriptor forprocessing by any of all of the resources 104, 108, 112 associated withresponding devices coupled to the presence server 118 via the network116.

Continuing to consider the arrangement of FIG. 2 from the perspective ofthe responding device 102 b, the arrangement further includes aresponding watcher component 204. The responding watcher component 204is configured to receive from a requesting device (e.g., the cameraphone 102 c), via the presence server 118, the descriptor of theresource 104, 108, 112 and a request related to the resource. Thepresence server 118 can send the descriptor and the request to theresponding watcher component 204 via the presence protocol using anotify command. The notify command including the descriptor and requestmay be sent to the responding watcher component 204 based on asubscription to the presence information of the requesting device 102 c,as a result of a directed publish/notify command sent by the requestingdevice 102 c for delivery to the responding device 102 b, or in responseto a fetch or polling request made by responding device 102 b.

As described below in conjunction with FIGS. 4-6, the descriptor of theresource can be included in the request itself or can be included in thepresence protocol commands, such as the notify command described above,used to carry the request from the requesting device to the respondingdevice. The descriptor can be used to associate the request with aparticular resource 104, 108, 112 available to the responding device 102b, and the request message can be used to carry the resource request. Assuch, the responding device 102 b can process multiple requests fordifferent resources 104, 108, 112 corresponding to the variousrequesting devices 102 c connected to the network 116.

Again considering the arrangement of FIG. 2 from the perspective of theresponding device 102 b, the responding presentity component 202 isfurther configured to send a response to the presence server 118replying to the request message. The responding presentity component 202can send the response to the presence server 118 by including theresponse in presence information as described in conjunction with FIGS.4-6 below. The presence information including the response can be sentto the presence server 118 via the presence protocol using either abroadcast or directed publish command.

According to an exemplary embodiment, the responding device can includea responding user agent (RSUA). The RSUA component is coupled to theresource 104, 108, 112 and to the responding presentity 202 and watcher204 components. Like the PUA and WUA components described above, theRSUA can interact with the responding presentity 202 and watcher 204components on behalf of a principal. Generally, the RSUA will interactwith the resource 104, 108, 112 as its principal, although the RSUA canalso interact with an owner of the resource as well as other principals.

The RSUA component can be configured to facilitate a sending of thedescriptor of the resource by the responding presentity component 202 toadvertise the resource to other presence entities coupled to the network116. The RSUA component can interact with the resource 104, 108, 112directly to determine and publish the descriptor or can provide anappropriate interface for an owner of the resource to publish thedescriptor of the resource using the presence protocol. To provide aninterface for the owner of the resource, the RSUA can be coupled to auser communication client 110 a or any number of associatedcommunication clients, such as an IM communication client 110 b, a phoneclient 110 c, an email client 110 d, a Multimedia Messaging Service(MMS) client 110 d, and a browser client 110 f (collectively,communication clients 110) as shown in FIG. 2.

For example, FIG. 3 illustrates an interface that may be used by anowner of the resource 104, 108, 112 to interact with the respondingpresentity component 202 to publish the descriptor of the resource.Using the IM client 110 b, the exemplary interface can be presented on adisplay 300 in the form a “friends list” 302, recognizable to thosefamiliar with IM applications. The friends list 302 can include thenames of human resource owners, e.g., John, Paul, George, and Ringo,and/or non-human resource owners, e.g., Server1. The friends list 302can also include information identifying the resources associated witheach of displayed owners that are offered to authorized requestingentities, as well as a status of the offered resources. For example, theresources associated with John in the exemplary list 302 can include aprint service that is not available (N/A), web services, including aphoto sharing service that is available, an IM service that isavailable, and a file system that is not available (N/A).

The interface 302 can also include an Actions menu item 306, suitablefor invoking commands associated with resources. The Actions menu caninclude entries 306 a to publish a resource, publish a response to arequest, publish a request associated with a resource, subscribe toinformation associated with a resource, and subscribe to informationassociated with a request related to resource. A corresponding dialogbox (not shown) can be presented to gather the necessary information toperform the selected action.

The RSUA can be further configured to facilitate a processing by theresource 104, 108, 112 of the request received by the responding watchercomponent 204. The RSUA can be configured to forward the request to theappropriate resource 104, 108, 112 for processing or can interpretand/or pre-process the request prior to its being forward to theresource. For example, if the request were related to accessing thephoto sharing web service 104 a illustrated in FIG. 2, the RSUA couldtranslate the request into an appropriate HTTP get request and thenforward the request to the web service for processing (e.g., serving arequested photo web page).

The RSUA can facilitate the processing of the request without any userintervention or, if appropriate, can provide a suitable interface forgathering information, such as authorization, from an owner of theresource. For example, the interface 302 shown in FIG. 3 is illustratedas presenting a dialog box 304 indicating that a user, George, hasrequested access to a printer service (e.g., service 104 c of FIG. 2) bysubmitting a print job request. The owner of the printer service caneither accept or deny the request by selecting the appropriate dialogbox control. If the request is accepted by the owner of the printerservice, the RSUA can forward the request to the printer service,performing any translations of the request as needed.

In addition, the RSUA can be further configured to facilitate a sendingof the response to the request by the responding presentity component202. As with the publishing of the descriptor, the RSUA component caninteract with the resource 104, 108, 112 directly to determine andpublish the response to the request or can provide an appropriateinterface for the owner of the resource to publish the response usingthe presence protocol. For example, upon selection of the “publish aresponse” entry included in the Action entry list 306 a of FIG. 3, anappropriate dialog box (not shown) can be presented to gather thenecessary information to form the response to the request. The RSUA canthen forward the response to the responding presentity component 202 forpublishing (perhaps with the assistance of an appropriate PUA),performing any translations of the response as needed.

In facilitating the exchange of information between the respondingpresentity 202 and watcher 204 components, the resource 104, 108, 112,and the communication clients 110, the RSUA may act in conjunction withappropriate PUAs and/or WUAs or may bypass the operation of theseagents. Moreover, it will be understood that the RSUA for a particularresource can be combined with the PUA and/or WUA associated with thatresource, or can be configured to act as a responding user agent for allresources associated with a particular device and/or owner. As with PUAsand WUAs, the RSUA can be implemented such that its functionality existswithin the presence service, external to the presence service, or acombination or both internal and external to the presence service.

Consider now the arrangement of FIG. 2 from the perspective of arequesting device, such as the camera phone 102 c shown in FIG. 1. Fromthis perspective, the arrangement includes a requesting watchercomponent 204 which can be configured to receive the descriptor of theresource 104, 108, 112 if sent from the presence server 118. Thepresence server 118 can send the descriptor to the requesting watchercomponent 204 via the presence protocol using a notify command. Thenotify command including the descriptor may be sent to the requestingwatcher component 204 based on a subscription to the presenceinformation of the responding device 102 b, as a result of a directedpublish/notify command sent by the responding device 102 b for deliveryto the requesting device 102 c, or in response to a fetch or pollingrequest made by the requesting device 102 c. The descriptor of theresource can be included in presence information associated with theresponding device or can be included in the presence protocol commands,such as the notify command described above, used to carry the presenceinformation from the responding device to the requesting device.

Continuing to consider the arrangement of FIG. 2 from the perspective ofthe requesting device 102 c, the arrangement further includes arequesting presentity component 202 configured to send the descriptorand the request related to the resource to the presence server 118. Therequesting presentity component 202 can send the request to the presenceserver 118 by including the request in presence information as describedin conjunction with FIGS. 4-6 below. The descriptor of the resource canbe included in the request itself or can be included in the presenceprotocol commands used to carry the presence information including therequest from the requesting device to the responding device. Thepresence information including the request can be sent to the presenceserver 118 via the presence protocol using either a broadcast ordirected publish command.

Again, considering the arrangement of FIG. 2 from the perspective of therequesting device 102 c, the requesting watcher component 204 is furtherconfigured to receive via the presence server 118 the response replyingto the request message. The presence server 118 can send the response tothe requesting watcher component 204 via the presence protocol using anotify command. The notify command including the response may be sent tothe requesting watcher component 204 based on a subscription to thepresence information of the responding device 102 b, as a result of adirected publish/notify command sent by the responding device 102 b fordelivery to the requesting device 102 c, or in response to a fetch orpolling request made by the requesting device 102 c.

According to an exemplary embodiment, the requesting device can includea requesting user agent (RQUA) component coupled to the requestingpresentity 202 and watcher 204 components. Like the RSUA, the RQUA canalso be coupled to the communication clients 110 a-110 f shown in FIG. 2for interacting with a user/principal of the requesting device 102 c.The RQUA can be configured to facilitate a presentation of thedescriptor received by the requesting watcher component 204. Forexample, using the IM client 110 b, the RQUA can present a descriptor ofa resource received by the requesting watcher component 204, such as thephoto sharing web service shown as being owned by John or the programsand service shown as being owned by Server1 in FIG. 2. The descriptorcan be presented in the interface 302 together with informationdescribing the owner of the resource and a status of the resource.

The RQUA can also be configured to facilitate a sending of the requestby the requesting presentity component 202. The request can beautomatically generated by the RQUA in response to some other actionoccurring in relation to the resource, e.g., an action by a relatedprogram running on the requesting device 102 c. Alternatively, aninterface, such as the interface 302 shown in FIG. 3, can be presentedto a user/principal of the requesting device 102 c to gather informationneeded to form the request. For example, upon selecting the “publish arequest” Action entry 306 a, a corresponding dialog box (not shown) canbe presented to a user/principal to gather the necessary information toform the request. The RQUA can then forward the request to therequesting presentity component 202 for publishing (perhaps with theassistance of an appropriate PUA), performing any translations of therequest as needed.

The RQUA can also be configured to facilitate a presentation of theresponse received by the requesting watcher component 204. For example,if the response were to include a web page served from the photo sharingweb service 104 a of the responding device 102 b illustrated in FIG. 2,the RQUA could invoke the browser client 110 f of the requesting device102 c shown in the figure to display the served web page. Thus, the RQUAcan effectively establish itself as a proxy for processing requestsdirected to and responses received from presence server 118.Alternatively, the RQUA can present a dialog box to receiveauthorization or additional information from a user/principal prior toacting on the response.

In facilitating the exchange of information between the requestingpresentity 202 and watcher 204 components and the communication clients110, the RQUA may act in conjunction with appropriate PUAs and/or WUAsor may bypass the operation of these agents. As with PUAs and WUAs, theRQUA can be implemented such that its functionality exists within thepresence service, external to the presence service, or a combination orboth internal and external to the presence service.

Referring again to FIG. 1, the presence server 118 can include the proxyservice 124. The proxy service 124 can be configured to send the requestto the responding watcher component 204 through a firewall 114associated with the responding device 102 b or to send the response tothe requesting watcher component through a firewall (not shown)associated with the requesting device 102 c. According to anotherexemplary embodiment, the presence server 118 can also include theaccount service 122. The account service 122 can be configured toauthenticate an identity of each of the requesting and respondingdevices and to authorize a receiving by each of the devices of therequest or the response prior to sending the request or response to therespective entity.

Rosters and/or privacy lists may be used by the account service 122 toauthorize and authenticate access to a particular resource or to preventproviders from advertising certain resources to subscribers. In thissense, the rosters and/or privacy lists can operate as access controllists (ACLs) for authenticating and authorizing resource usage amongpresence entities. The roster and/or privacy list data can be stored ina database, such as the account and authorization information database128 coupled to the account service 122. Multiple rosters and/or privacylists may be maintained in the database 128 and used by the service 122.No new extension to the account service protocol for roster managementis required to maintain the rosters or lists, however, the roster datacan instead be included in presence information and carried by thepresence protocol.

Referring now to FIG. 4, a data structure is illustrated for use with apresence protocol in providing a general request/response protocol. Forconvenience, the data structure shown in FIG. 4 includes data objectsand elements for storing the presence information of both a respondingentity and a requesting entity. Nevertheless, persons skilled in the artwill understand that a data structure for storing the presenceinformation associated with a responding device need not include theobjects and elements necessary to store the presence information of arequesting device, and vice versa.

Should the data structure of FIG. 4 include data objects and elementsfor storing the presence information of both a responding and requestingentity, one of the following arrangements may exist: 1) the respondingand requesting entities are associated with the same principal, and areresponding to and making requests related to different resources; or 2)the responding and requesting entities are associated with differentprincipals, and are responding to and making requests related to acommon resource. This second arrangement requires a change to thestandard presence services access control policies, and could lead to amore complex access control system. Nevertheless, performing the entirerequest/response transaction using information stored in a singlepresence tuple associated with the resource or owner of the resourcecould lead to efficiencies in data storage usage and data exchange.

The data structure shown in FIG. 4 may be contained in any suitablecomputer readable medium, including any means that can contain, store,communicate, propagate, or transport the program for use by or inconnection with the instruction execution system, apparatus, or device.The computer readable medium can be, for example but not limited to, anelectronic, magnetic, optical, electromagnetic, infrared, orsemiconductor system, apparatus, device, or propagation medium, such asa removable storage device. More specific examples (a non-exhaustivelist) of the computer readable medium can include the following: anelectrical connection having one or more wires, a portable computerdiskette, a random access memory (RAM), a read only memory (ROM), anerasable programmable read only memory (EPROM or Flash memory), anoptical fiber, and a portable compact disc read only memory (CDROM).

The data structure shown in FIG. 4 represents presence information 400that includes an enhanced presence tuple 402. The presence information400 can be stored in a database coupled to the presence server 118 shownin FIG. 1, such as the presence information database 126. Although asingle database 126 is shown in FIG. 1, persons skilled in the art willunderstand that the presence information can be distributed throughoutthe network 116 across multiple databases and/or stored, at least inpart, in memory associated with the requesting and/or responding devices102 shown in FIG. 1.

The presence tuple 402 shown in FIG. 4 includes standard data objectsfor storing the status 404 and communication address 406 informationdescribed in RFC 2778 and RFC 2779. The presence tuple 402 also includesdata objects for storing a contact means 408 and contact address 410, aswell as a data object for storing other markup 418, thus maintaining theextensibility of the tuple 402 in accordance with presence standards.Because the presence tuple 402 maintains the standard form for presenceinformation described in RFC 2778 and RFC 2779, the presence information400 can be carried across the network 116 using standard presenceprotocol commands. It is not necessary that the presence server 118 tounderstand the content of the tuple 402 in order to route theinformation contained therein to the various presence entities coupledto the network 116.

Considering first the data structure of FIG. 4 from the perspective of aresponding entity, to provide a general request/response protocol usinga presence protocol, the presence tuple 402 includes a resource dataobject 412, including an element (not expressly shown) for storing adescriptor of a resource associated with a responding entity. Asdescribed in conjunction with FIGS. 1-3 above, the descriptor caninclude any information that describes and/or identifies the resourceavailable to the responding entity, such as any of the resources 104,108, 112 shown in FIG. 1. The responding entity can be, for example, theresponding presentity component 202 shown in FIG. 2. According to anexemplary embodiment, the resource data object 412 can also include atleast one element (not expressly shown) for storing informationdescribing the requests supported by the resource, including informationdescribing the types of functions and requests that the resource cansupport and information describing how to format the requests. Theresource data object 412 can also include at least one element (notexpressly shown) for storing information describing the responsesavailable for replying to the requests supported by the resource.

Now, considering the data structure of FIG. 4 from the perspective of arequesting entity, the presence tuple 402 also includes a request dataobject 416. The request data object includes an element for storing arequest from a requesting entity related to the resource. The requestingentity can be, for example, the requesting presentity component 202shown in FIG. 2.

FIG. 5A shows an expanded view of the request data object 416 accordingto an exemplary embodiment. As shown in the figure, the expanded view ofthe request data object 416 can include an element for storing a requestmessage 504 related to the resource. The request data object 416 canalso include a descriptor element 502 for storing a descriptor of aresource associated with the responding entity. The descriptor element502 can include information to describe or identify only the resource,or can include information to describe or identify both the respondingentity and its associated resource(s), such as a Uniform ResourceIdentifier (URI).

For example, consider the following XML-based message published by arequesting entity (“customer@isp.net”) for notification to an onlinestore, “online.com” that includes a service (or resource) for orderingbooks:

<presencefrom=‘customer@isp.net’to =‘sales@online.com’xml:lang=‘en’><request><descriptor>books</descriptor></request></presence>The descriptor stored in element 502 could be simply “books” (asindicated) to identify the resource, or the descriptor could be a fullURI, e.g., “sales@online.com/books”, to identify both the respondingentity (e.g., by node and domain name) and the resource. It should beunderstood that the responding entity can correspond to the resourceitself, and thus the descriptor can describe or identify the respondingentity/resource using a simpler URI, such as the URI “books@online.com”.The presence server 118 can use the descriptor stored in the element 502both to route the request message stored in element 504 to therequesting entity/resource (e.g., using the node and domain portion of aURI descriptor) and to describe or identify the resource to process therequest (e.g., using the identifier portion of a URI descriptor.

It can be useful to include the descriptor in the request undercircumstances when the requesting entity's identifying information isbeing sent to all watching entities that may be subscribed to therequest or when the presence information that includes the request isbeing broadcast to all watching entities coupled to the network 116(i.e., when a directed publish/notify command is not used). For example,consider the following XML-based message published by a requestingentity (“customer@isp.net”) for broadcast to any available respondingentity/resource:

<presencefrom=‘customer@isp.net’xml:lang=‘en’><request><descriptor>sales@online.com/books</descriptor></request></presence>Broadcasting to all entities can be useful when the responding entityhas not subscribed to at least the presence information of therequesting entity that includes the request.

FIG. 5B shows an expanded view of the request data object 416 accordingto an alternative embodiment. In this embodiment, the request dataobject 416 does not include an element for storing the descriptor of theresource associated with the responding entity (e.g., element 502 shownin FIG. 5A). Instead, the descriptor of the resource can be included inthe presence protocol commands used to carry the request from therequesting device to the responding device. For example, consider thefollowing XML-based message published by a requesting entity(“customer@isp.net”) for notification to the online store describedabove:

<presencefrom=‘customer@isp.net’to =‘sales@online.com/books’xml:lang=‘en’><request> . . . </request></presence>Rather than including the descriptor for the “books” service offered bythe online store in the request message itself (e.g., between the<request> and </request> elements of the message), the descriptor can beincluded in a presence attribute, “sales@online.com/books”, used by thepresence server 118 to route the notify portion of the directedpublish/notify command to the responding entity.

It can also be useful for the requesting entity to broadcast astandardized request without a particular resource descriptor when therequesting entity has no preference as to the responding entity/resourcethat processes and responds to the request. Consequently, the requestcan be processed by any available responding entity/resource. Forexample, consider the following XML-based message published by arequesting entity (“customer@isp.net”) for broadcast to any availableresponding entity/resource:

<presencefrom=‘customer@isp.net’xml:lang=‘en’><request> . . . </request></presence>Since the broadcast message including the request does not include adescriptor of a resource to process the request (either in a presenceattribute of the message or in the request itself), any watchingentity/resource can evaluate the request, and process and respond to therequest if appropriate.

In a related embodiment, the request data object can also include anelement for storing an identifier of the responding entity. For example,the expanded view of the exemplary request data object 416 shown in FIG.5B includes an identifier element 506 for storing an identifier of theresponding entity. The identifier can be a URI including a node anddomain of a responding entity, such as “sales@online.com”. Such anidentifier can be used by the requesting entity when broadcasting arequest to all watching entities (e.g., for notice purposes), but whenthe request is to be processed by only the responding entitycorresponding to the identifier.

For example, consider the following XML-based message published by arequesting entity (“customer@isp.net”) for broadcast to any availableresponding entity/resource, but including an identifier in the requestfor identifying a responding entity having a resource available toprocess the request:

<presencefrom=‘customer@isp.net’xml:lang=‘en’><request><identifier>sales@online.com</identifier></request></presence>In this sense, the identifier stored in element 506 serves a similarfunction to the descriptor stored in element 502 of the arrangementshown in FIG. 5A. The identifier, however, need not include a descriptorof the resource used to process the request. Thus, if the respondingentity corresponding to the identifier has access to a number ofresources, any one of those resources can be used to process therequest.

According to another exemplary embodiment, the request message stored inelement 504 can be an XML-based message formed in the structure of aSOAP message. SOAP is a standard for exchanging XML-based messages overa computer network, typically using HTTP. SOAP forms the foundationlayer of a protocol stack for providing web services. The standardprovides a basic messaging framework that more abstract layers in thestack can build on.

There are several different types of messaging patterns available inSOAP, but the most common is the Remote Procedure Call (RPC) pattern,where one network node (the client) sends a request message to anothernode (the server), and the server immediately sends a response messageto the client. SOAP originally was an acronym for Simple Object AccessProtocol, but the acronym has been dropped in Version 1.2 of the SOAPspecification. A primer for this version of the standard, published bythe World Wide Web Consortium (W3C) XML Protocol Working Group could bedownloaded or viewed fromhttp://www.w3.org/TR/2003/REC-soap12-part0-20030624/ at the time thisapplication was filed.

Referring once again to the data structure of FIG. 4 from theperspective of a responding entity, the presence tuple 402 also includesa response data object 414 including an element for storing a responsefrom the responding entity replying to the request message. Theresponding entity can be, for example, the responding presentitycomponent 202 shown in FIG. 2. It should be noted that FIG. 4 depictstwo response data objects 414 linked to the resource data object 412 inthe presence tuple 402. Such an arrangement allows for the efficientstorage and management of the information needed to respond to multiplerequests (from, e.g., multiple presence entities) that are related to acommon resource. Nevertheless, the arrangement shown in FIG. 4 is merelyexemplary, and other arrangements for storing and managing the resource,request, and response information are within the scope of the techniquesdescribe here.

FIG. 6 shows an expanded view of the response data object 414 accordingto an exemplary embodiment. As shown in the figure, the expanded view ofthe response data object 414 can include an element for storing aresponse message 604 replying to the request message stored in element504. Similar to the request message, the response message stored inelement 604 can be an XML-based message formed in the structure of aSOAP message.

The response data object 414 can also include an identifier element 602(similar to the identifier element 506 shown in FIG. 5B) for storing anidentifier, such as a URI, of the requesting entity. The presence server118 can use the identifier stored in the element 602 to route theresponse message stored in element 604 of the presence tuple 402 to therequesting entity. It can be useful for the presence server 118 to usethis identifier under circumstances when both the responding entity'spresence information is being broadcast to all presence entities coupledto the network 116 (i.e., when a directed publish/notify command is notused) and the requesting entity has not subscribed to at least thepresence information of the responding entity that includes the responsemessage, or when there is a need to notify other subscribed watchers ofthe response.

For example, consider the following XML-based message published by aresponding entity (“sales@online.com”) for broadcast to any availablerequesting entity:

<presencefrom=‘sales@online.com’xml:lang=‘en’><response><identifier>customer@isp.net</identifier></response></presence>Notwithstanding the message being broadcast to all watching entities,the identifier can be used by the requesting entity (“customer@isp.net”)to determine that the response is in reply to its own request. Whenthere is no need to notify other subscribed watchers of the response, adirected publish/notify of the response to the requesting entity can beused, making it unnecessary to store the identifier of the requestingentity in the response data object 414.

Most presence protocols are XML-based (e.g., text-based) protocols.Should it be necessary to include binary data in either the request orresponse message, the binary data can be supported through the use ofattachments. For example, the document “SOAP with attachments”,published by the W3C and available for downloading or viewing fromhttp://www.w3.org/TR/2004/NOTE-soap12-af-20040608/ at the time thisapplication, describes SOAP support for binary attachments.Alternatively, binary data may be passed in the request/responsemessages by reference. That is, URIs may be passed in the XML-basedrequest/response messages, using which a presence entity and/or agentmay retrieve the binary data. It is preferred that binary data passthrough and/or be stored in a presence tuple encoded in a text format,such that presence server 118 can apply security, tracking, andmanagement services to this type of data as well by treating it just asany other piece of tuple data.

In an exemplary embodiment, the resource 412 and response 414 dataobjects can be included in a presence tuple associated with the resourceor an owner of the resource. When the resource 412 and response 414 dataobjects are included in a presence tuple associated with the resource,the presence tuple associated with the resource can include a dataobject linking the presence tuple associated with the resource to apresence tuple associated with the owner of the resource.

For example, FIG. 7 depicts a data structure for storing presenceinformation associated with an IM resource, such as the IM client 110 bshown in FIG. 2. The presence information 400 includes an IM presencetuple 702 corresponding to the IM client 110 b, and other IM presencetuples 702 corresponding to other IM clients (not shown) coupled to thenetwork 116. The IM presence tuple 702 includes standard data objectsfor storing a service status 704, a communication address 706, includingelements for storing a contact means 708 and contact address 710, and adata object for storing other markup information 418. The informationstored in the status 704 and communication address 706 data objects canrepresent the status and communication address of an owner or principalassociated with the IM client 110 b and/or the status and communicationaddress of the IM client 110 b.

Since the IM presence tuple 702 is associated with a resource (e.g., theIM client 110 b) and not the owner of the resource, the IM presencetuple 702 can also include a data object 712 for storing informationlinking information in the owner/principal's presence tuple (not shown)to the IM presence tuple 702. Moreover, since the IM present tuple 702is itself associated with the resource, a resource data object, such asthe resource data object 412 shown in FIG. 4, is not required. Instead,the descriptor of the IM service, along with any other information aboutthe service, such as the types of functions and requests that theservice supports and how to format requests to the service, can bestored in other data objects and/or elements (not expressly shown) ofthe IM presence tuple 702.

The IM presence tuple 702 can also include a request data object 714,including identifier 716 and message 718 elements, as well as subject720 and body 722 sub-elements, for storing IM message information tosend to other presence entities coupled to the network 116. A presentityassociated with IM client 110 e can use directed publish/notify commandsto send messages to specific entities, or can broadcast messages to allsubscribers to the IM presence tuple 702 information. Because the IMpresence tuple 702 maintains the standard form for presence informationdescribed in RFC 2778 and RFC 2779, the presence information 400 can becarried across the network 116 using standard presence protocolcommands. It is not necessary that the presence server 118 to understandthe content of the tuple 702 in order to route the information containedtherein to the various presence entities coupled to the network 116.Moreover, the arrangement shown in FIG. 7 allows both conventionalpresence information and IM messaging information to be carried solelyby the presence protocol, eliminating the need to use a separatemessaging protocol to send the IM message content.

In a related exemplary embodiment, the request data object 416 can beincluded in a presence tuple associated with the resource or a principalassociated with the requesting entity. When the request data object 416is included in a presence tuple associated with the resource, thepresence tuple associated with the resource can include a data objectlinking the presence tuple associated with the resource to a presencetuple associated with the principal associated with the requestingentity.

FIG. 8 is a flowchart illustrating a method for providing a generalrequest/response protocol using a presence protocol. The method can becarried out using the arrangement described in conjunction with FIGS.1-3 and the data structure described in conjunction with FIGS. 4-6above, portions of which are referenced in the description that follows.In particular, the method can be carried out using the presence server118. It will be understood that other arrangements and/or datastructures can be used to carry out the described method withoutdeparting from the scope of the described techniques. Descriptions ofcertain terms, the meanings of which are described in detail above inconjunction with FIGS. 1-6, are not repeated here.

Moreover, the executable instructions of a computer program asillustrated in FIG. 8 for providing a general request/response protocolusing a presence protocol can be embodied in any computer readablemedium for use by or in connection with an instruction execution system,apparatus, or device, such as a computer based system, processorcontaining system, or other system that can fetch the instructions fromthe instruction execution system, apparatus, or device and execute theinstructions.

The method begins in block 802, at which the presence protocol is usedfor receiving, from a requesting entity, a descriptor of a resourceassociated with a responding entity and a request related to theresource. For example, the presence server 118 can receive thedescriptor and the request from the requesting presentity component 202shown in FIG. 2. In block 804, the descriptor and the request are sent,e.g., from the presence server 118, to the responding entity, e.g., theresponding watcher component 204. The descriptor can be included in therequest as described above in conjunction with the request data object416 shown in FIG. 5A. Alternatively, the descriptor can be included ineach of respective presence protocol commands, e.g., publish and notifycommands, used in receiving the request from the requesting entity andin sending the request to the responding entity.

A response from the responding entity, e.g. the responding presentitycomponent 202 of FIG. 2, is received, e.g. by the presence server 118,in block 806. The response can include a response message replying tothe request message, stored, for example, in element 604 of the datastructure shown FIG. 6, and an identifier of the requesting entity,stored, for example, in element 602 of the data structure. In block 808,the response is sent, e.g., by the presence server 118, to therequesting entity, e.g., the requesting watcher component 204 shown inFIG. 2. Accordingly, a general request/response protocol is formed usingthe commands of a presence protocol.

According to an exemplary embodiment, the presence protocol can be usedfor receiving, e.g., by the presence server 118, the descriptor of theresource from the responding entity, e.g., the responding presentitycomponent 202 shown in FIG. 2. The descriptor of the resource can besent to the requesting entity based on a subscription established forthe requesting entity to at least some presence information of theresponding entity, for example, the presence information stored in theresource data object 412. The presence protocol can be used forautomatically establishing a subscription for the responding entity toat least some presence information of the requesting entity, forexample, the presence information stored in the request data object 416,when the subscription to the presence information of the respondingentity is established for the requesting entity 102. The request sent tothe responding entity can be based on the subscription automaticallyestablished for the responding entity. The automatic subscriptionprovides an efficient mechanism of allowing the responding entity to benotified of requests from requesting entities that have subscribed toinformation associated with the resource.

If automatically establishing a subscription is not desired, thepresence protocol can be used in an alternative embodiment for sending anotification to the responding entity indicating that the subscriptionto at least some of the presence information of the responding entity,for example, the presence information stored in the resource data object412, is established for the requesting entity. A subscription requestcan be received from the responding entity in response to thenotification, requesting a subscription to at least some presenceinformation of the requesting entity, for example, the presenceinformation stored in the request data object 416. The subscription tothe presence information of the requesting entity can then beestablished for the responding entity based on the received subscriptionrequest. The request sent to the responding entity can then be based onthe subscription established for the responding entity.

In another embodiment, the presence protocol can be used for sending thedescriptor of the resource to the requesting entity in response to afetching or a polling request by the requesting entity for at least somepresence information of the responding entity. For example, rather thansubscribe to the presence information of the responding entity to benotified when new resources are made available, the requesting entitycan request that the presence server 118 probe the presence informationof the responding entity on a periodic basis to determine if a newresource has been published, and to notify the requesting entity of sucha publication.

The request sent to the responding entity can be based on a subscriptionestablished for the responding entity to at least some presenceinformation, for example, the presence information included in therequest data object 416, of the requesting entity. Alternatively, therequest can be sent to the responding entity using an identifier of theresponding entity included in presence information of the requestingentity. Thus, rather than notifying the responding entity of the requestbased on a subscription request, the presence server 118 can notify theresponding entity of the request based on a directed publish/notify ofthe request information sent from the requesting entity. The request canalso be sent to the responding entity in response to a fetching or apolling request by the responding entity for at least some presenceinformation of the requesting entity. Accordingly, the presence server118 can probe the presence information of the requesting entity on aperiodic basis for the request information pursuant to a polling orfetch request received from the responding entity. The presence server118 can then notify the responding entity of the request when detectedvia the probe command.

Likewise, the response sent to the requesting entity can be based on asubscription established for the requesting entity to at least somepresence information, for example, the presence information included inthe response data object 414, of the responding entity. Alternatively,the response can be sent to the requesting entity using an identifier ofthe requesting entity included in presence information of the respondingentity. Thus, rather than notifying the requesting entity of theresponse based on a subscription request, the presence server 118 cannotify the requesting entity of the response based on a directedpublish/notify of the response information sent from the respondingentity. The response can also be sent to the requesting entity inresponse to a fetching or a polling request by the requesting entity forat least some presence information of the responding entity.Accordingly, the presence server 118 can probe the presence informationof the responding entity on a periodic basis for the responseinformation pursuant to a polling or fetch request received from therequesting entity. The presence server 118 can then notify therequesting entity of the response when detected via the probe command.

According to an exemplary embodiment, the request can be included inpresence information associated with the requesting entity but is notincluded in presence information associated with the responding entity.Similarly, the response can be included in the presence informationassociated with the responding entity but is not included in thepresence information associated with the requesting entity.Consequently, each of the requesting and responding entities publishpresence information only to their respective presence tuples. With suchan arrangement, the presence service 120 and its underlying presenceprotocol need not be modified to allow for the exchange ofrequest/response information included in the presence tuples.

In a related embodiment, the presence information associated with theresponding entity can correspond to presence information of the resourceor presence information of an owner of the resource. When the presenceinformation associated with responding entity corresponds to presenceinformation of the resource, the presence information of the resourcecan include a link to the presence information of the owner of theresource. In another related embodiment, the presence informationassociated with the requesting entity can correspond to presenceinformation of a second resource associated with the requesting entityor presence information of an owner of the second resource, the secondresource being configured to form the request. The reader is referred toFIG. 7, depicting a data structure for storing presence informationassociated with an IM resource, and its associated text for detailsregarding the linking of presence information of a resource and thepresence information of an owner/principal of the resource.

According to an exemplary embodiment, an identity of each of therequesting and responding entities can be authenticated and a receivingby each of the entities of the request or the response can be authorizedprior to sending the request or response to the respective entity. Forexample, as described above, the presence server 118 can include theaccount service 122 configured to authenticate an identity of each ofthe requesting and responding devices and to authorize a receiving byeach of the devices of the request or the response prior to sending therequest or response to the respective entity. In addition, rostersand/or privacy lists may be used by the account service 122 to authorizeand authenticate access to a particular resource or to prevent providersfrom advertising certain resources to subscribers.

In another exemplary embodiment, a proxy service can be provided forsending the request to the responding entity through a firewallassociated with the responding entity or for sending the response to therequesting entity through a firewall associated with the requestingentity. For example, referring to FIGS. 1 and 2, the presence server 118can include a proxy service 124 configured to send the request to aresponding watcher component 204 through a firewall 114 associated withthe responding device 102 b, or to send the response to a requestingwatcher component through a firewall (not shown) associated with therequesting device 102 c.

According to another embodiment, the presence protocol can be used forreceiving from the responding entity a second descriptor of a secondresource associated with a second responding entity and a second requestrelated to the second resource. The second request can be related to theresponse replying to the request from the requesting entity. Thepresence protocol can also be used for sending the second descriptor andthe second request to the second responding entity. Consequently, theoriginal responding entity can function as a requesting entity and canmake requests of other responding entities when processing the originalreceived request. Such an arrangement can be used to support workflowsamong various presence entities to efficiently carry out complexmulti-entity transactions.

For example, FIG. 9 illustrates the flow of information among presenceentities that can occur in carrying out a multi-entity online purchasetransaction. The arrangement of FIG. 9 includes a presence server 902and presence entities representing a customer 906 and an online store904. Additional presence entities representing a shipping provider 908and a credit provider 910 are also shown. The customer entity 906 canbegin a transaction by publishing, to the presence server 902, presenceinformation 912 including a request to purchase a book from the onlinestore entity 904. The presence information 912 includes an identifier(“customer@isp.net”) of the customer entity 906 as a “from” presenceattribute, and an identifier/descriptor (“sales@online.com/books”) of aresource associated with the online store entity 904 as a “to” presenceattribute of a directed publish/notify command. Alternatively, thepresence information 912 could be broadcast to the presence server 902by the customer entity 906.

The request included in the presence information 912 can includeinformation specifying the title of the book (“My Book”), the quantityto be ordered (“1”), payment information, including a payment type, suchas a credit card (“Card”), and other related payment informationincluding a card number (“999999999”) and expiration date (“0808”). Therequest can also include shipping information, including a shippingtype, such as by parcel post (“Parcel”), and other related shippinginformation including a shipping address (“1234 Street City, ST,00000”).

Once published, the presence information 912 including the request canbe sent by the presence server 902 to the online store entity 904. Thepresence information 912 including the request can be sent to the onlinestore entity 904 via the notify portion of a directed publish/notifycommand (as shown), or can be sent via a notify command in response to asubscription by the online store entity 904 to the presence information912 of the customer entity 906. The request can then be processed by theonline store's “books” service. In processing the request from thecustomer entity 906, the online store entity 904 may broadcast requeststo the presence server 902 for notification to other respondingentities, such as the shipping 908 and credit 910 provider entities.Each of these entities can be subscribed to the presence information 914of the online store entity 904 as denoted by the dotted lines includedin the figure. The presence information 914 broadcast by the onlinestore 904 entity can include requests for the shipping 908 and credit910 provider entities.

Each of the shipping 908 and credit 910 provider entities can receivenotifications from the presence server 902 pursuant to theirsubscriptions to the presence information 914 of the online store entity904. For example, the shipping provider entity 908 can receive presenceinformation 916 including the online store's shipping request. Theshipping request can result in one title of the book “My Book” beingshipped to the address included in the presence information 912 of thecustomer entity 906. In addition, the credit provider entity 910 canreceive presence information 918 including the online store's creditrequest. The credit request can result in credit from the account“999999999” being provided by the credit provider entity 910 on behalfof the customer entity 906 for the purchase price of the book.

Note that the credit provider entity 910 can also be subscribed to thepresence information 912 of the customer entity 906 (again, as denotedby the dashed line in the figure). As a result of the subscription, thecredit provider entity 910 can preprocess a request for credit from theonline store 904 on behalf of the customer entity 906 at the time therequest to purchase the book is made by the customer entity 906.Consequently, credit can be pre-approved for the purchase at the timethe order is fulfilled by the online store, resulting in an overall moreefficient transaction.

In an alternate embodiment, rather than the online store entity 904issuing a request directed to the shipping provider 908 and the creditprovider 910 entities as described above, the shipping provider 908 andcredit provider 910 entities can receive notifications related to theirservices pursuant to outstanding subscriptions to all responsespublished by the online store entity 904 that specify their services.Such an arrangement allows the shipping provider 908 and credit provider910 entities to monitor the request/response transaction between thecustomer entity 906 and online store entity 904 for relevant transactioninformation.

For example, consider when the online store entity 904 publishes aresponse to the customer entity's 906 request for a book purchase, thecustomer can receive a notification that the order is “in process”. Theshipping provider 908 and credit provider 910 entities, which aresubscribed to the published response, receive first notificationspursuant to their existing subscriptions. The credit provider entity 910may ignore this first notification, for example, if shipping costs havenot been calculated and included in the published presence information.The shipping provider entity 908 can publish data (or send the dataoutside the presence service or “out-of-band”) to the online store 904providing shipping charges and perhaps a pickup date.

The online store 904 entity can then update its response tuple with thenew shipping information and publish this information to the presenceserver 902. At this point, the customer 906 entity can receive anotification with the new shipping information and perhaps a newtransaction status indicator, such as “shipping approved”. The creditprovider entity 910 can receive a second notification based on itssubscription to the online store entity's 904 response. The creditprovider entity 910 can determine from the notification that a totaltransaction cost (e.g., cost of the book plus the new shipping charges)is now available. The credit provider entity 910 can then approve thecharges and publish data (or send the data out-of-band) to the onlinestore entity 904 indicating that the charge has been approved. Theonline store entity 904 can then publish new status information to theexisting response tuple indicating that the status of the transaction is“order completed”. The customer entity 906 can then receive anotification from the presence server 902 with the new statusinformation.

Instead of the requesting and responding entities publishing presenceinformation only to their respective presence tuples, a method is nowdescribed that allows a requesting entity to update the respondingentity's presence information by adding a request related to theresource to the responding entity's presence tuple. With thismethodology, the entire request/response transaction can occur usinginformation stored in a single presence tuple. For example, the datastructure shown in FIG. 4 can be configured to store the presenceinformation of both a responding and requesting entity. But rather thanthe responding and requesting entities being associated with the sameprincipal and configured to respond to and make requests related todifferent resources (as described in conjunction with method illustratedin FIG. 8), the responding and requesting entities can be associatedwith different principals and configured to respond and make requestsrelated to a common resource.

As described above, such a methodology requires a change to the standardpresence services access control policies, and could lead to a morecomplex access control system. Nevertheless, performing the entirerequest/response transaction using information stored in a singlepresence tuple associated with the resource or owner of the resourcecould lead to efficiencies in data storage usage and data exchange.

The exemplary method includes receiving presence information from aresponding entity including a descriptor of a resource associated withthe responding entity. A request is received along with a descriptorrelated to the resource from a requesting entity. The request include arequest message related to the resource. The presence information of theresponding entity is updated to include the request message. Thepresence information is received from the responding entity, including aresponse message replying to the request message. The response messageis then sent to the requesting entity.

ILLUSTRATIVE EXAMPLE

The following illustrative example is provided in conjunction with thesignal flow diagram shown in FIG. 10 to clarify the concepts describedabove. The actions carried out in the example are for illustrativepurposes, and should not be construed as being limiting in any way. Norshould the numerical order of the steps, either in the text below or asshown in FIG. 10, be construed as limiting or necessary in any way. Inthe example, users (through their presence entities and agents) areallowed to update only their own presence tuples. This approach allows arequest response protocol to be provided using a presence protocolwithout having to change the structure of the underlying presenceservice.

The example is directed to an arrangement in which a standard presencetuple is extended to support a web service resource, such as the photosharing web service 104 a shown in FIG. 2. The photo sharing service canbe a web site accessible or hosted by a responding entity, such as thePC 102 b. The PC 102 b can include a presentity component/PUA, a watchercomponent/WUA and various communication clients 110. The PC 102 b can beprotected by a firewall 114.

First, a resource data object 412 is added to a standard presence tuple402 in the portion intended for extended data, as shown in FIG. 4. Inthe example, the presence tuple 402 corresponds to an owner, Xena, ofthe web service, but could correspond to the web server itself. Theresource data object 412 is used to store information, such as adescriptor, related to the photo sharing service. In addition, one ormore response data objects 414 are added to the presence tuple 402 tostore responses to requests made to the service.

The resource 412 and response 414 data objects can be added to thepresence tuple 402 using an RSUA associated with the photo sharingservice. The RSUA is an extension to the Xena's presentity and also isconfigured to update the resource 412 and response 416 data objects ofXena's presence tuple 402 with corresponding service and responseinformation. For example, the RSUA can detect the activity of the website on the PC 102 b and update, in action 1002, the service owner's(Xena's) presence tuple 402 with information, such as a servicedescriptor, related to the web service. The RSUA can then facilitate theadvertising of the photo sharing service to other presence entities inaction 1004 by instructing Xena's presentity (and any associated PUA) topublish the presence information including the descriptor of the photosharing service.

In the example, a friend of Xena, Mike, operates a requesting device,such as the camera phone 102 c. The camera phone 102 c can include apresentity component/PUA, a watcher component/WUA and variouscommunication clients 110, such as the IM client 102 b and the browser110 f client. The browser client 110 f can be used for exchanginginformation with web services, such as Xena's photo sharing service. Thecamera phone 102 c can also be protected by a firewall (not shown).

Mike subscribes to Xena's presence tuple 402 in action 1006. Mike'ssubscription can cause a subscription to be automatically established toMike's presence tuple on behalf of Xena's presentity in action 1008.Alternatively, Mike's presentity component can notify Xena of hissubscription, allowing Xena to then request a subscription to Mike'spresence tuple. The subscription to Mike's presence tuple allows Xena'swatcher component to be notified of photo sharing service requests thatare published with Mike's presence tuple. An account service 122 can beincluded in the presence server 118 for authenticating Mike's and Xena'sidentities to the other, and for authorizing the receiving ofinformation from the presence service 118.

In action 1010, Mike's watcher receives a notify message from thepresence server 118 in response to the subscription established inaction 1006. A proxy service 124 can be used to route the notify messagethrough Mike's firewall (not shown). The notify message sent in action1006 includes the descriptor of Xena's photo sharing service. The cameraphone 102 c can include a RQUA that is configured to process Xena'spresence information in cooperation the WUA. The RQUA can display thepresence information, including the descriptor of the photo sharingservice, in action 1012 using an appropriate communication client, suchas the IM client 102 b shown in FIG. 2.

The RQUA can also be configured to add a request data object 416 toMike's presence tuple. The request data object 416 can be added to theportion of the presence tuple 402 intended for extended data, as shownin FIG. 4. In response to Mike selecting Xena's web service using the IMclient 110 f, the RQUA (in cooperation, perhaps, with the PUA) can useother information included in the resource data object 412 of Xena'spresence tuple, such as information describing the form of servicerequest, to include a request message, in action 1014, in the requestdata object 416 of Mike's presence tuple along with the descriptor ofthe photo sharing service. The request can be for a web page advertisedas being available through Xena's photo sharing server. The RQUA theninstructs the camera phone's presentity to publish the request in action1016.

In action 1018, the presence server 118 sends a notify command to Xena'swatcher component pursuant to the subscription request established inaction 1008. Again, the proxy service 124 can be used to route thenotify message through Xena's firewall 114. Xena can be informed of therequest, or the request can be automatically processed in action 1020using the PC's RSUA and/or WUA. For example, the RSUA can convert therequest for a particular web page into an appropriate HTTP request thatcan be routed to the photo sharing service for processing. The RSUA thenreceives the response from the photo sharing service, and perhapsconverts the response to an appropriate message format for transmission.In action 1022, the response message is stored in the response dataobject 414 of Xena's presence tuple. The RSUA then instructs Xena'spresentity to publish the presence tuple, including the response, to thepresence server 118 in action 1024.

In action 1026, the presence server sends a notify command to Mike'swatcher component pursuant to the subscription request established inaction 1006, again perhaps using the proxy service 124. Mike can beinformed of the response or the response can be automatically processedin action 1028 using the camera phone's RQUA and/or WUA. For example,the RQUA can convert the response message including the requested webpage into an appropriate HTTP response that can be routed to Mike'sbrowser client 110 f for displaying the requested web page on thedisplay of Mike's camera phone 102 c.

Methods, system, and data structure for providing a generalrequest/response messaging protocol using a presence protocol have beendescribed. Using the techniques described here, the publish-subscribemechanisms of the presence protocol can be expanded to provide generalrequest/response services. The resultant general request/responseprotocol includes the advantageous features of a presence service,including authentication, authorization, security, and proxies forfirewall piercing. The techniques described here allow for thedevelopment of enhanced applications, services, and workflows havingcharacteristics not present in conventional applications, services, andworkflows that use a presence protocol or a request/response protocolalone. In addition, the presence service supports centralized,distributed, peer-to-peer, and mixed architectures for implementing suchenhanced applications, services, and workflows.

It will be appreciated by those of ordinary skill in the art that theconcepts and techniques described here can be embodied in variousspecific forms without departing from the essential characteristicsthereof. The presently disclosed embodiments are considered in allrespects to be illustrative and not restrictive. The scope of theinvention is indicated by the appended claims, rather than the foregoingdescription, and all changes that come within the meaning and range ofequivalence thereof are intended to be embraced.

1. A method for providing a general request/response protocol, themethod comprising: receiving, by a server from a requesting entity usinga publish-subscribe protocol, a descriptor of a resource associated witha responding entity and a request related to the resource; sending, bythe server using the publish-subscribe protocol, the descriptor and therequest to the responding entity; receiving, by the server using thepublish-subscribe protocol, a response from the responding entityreplying to the request; and sending, by the server using thepublish-subscribe protocol, the response to the requesting entity. 2.The method of claim 1 further comprising using, by the server, thepublish-subscribe protocol for receiving the descriptor of the resourcefrom the responding entity.
 3. The method of claim 2 further comprisingusing, by the server, the publish-subscribe protocol for sending thedescriptor of the resource to the requesting entity based on asubscription established for the requesting entity to at least somepresence information of the responding entity.
 4. The method of claim 3further comprising using, by the server, the publish-subscribe protocolfor: automatically establishing a subscription for the responding entityto at least some presence information of the requesting entity when thesubscription to the presence information of the responding entity isestablished for the requesting entity; wherein sending the request tothe responding entity is based on the subscription automaticallyestablished for the responding entity.
 5. The method of claim 3 furthercomprising using, by the server, the publish-subscribe protocol for:sending a notification to the responding entity indicating that thesubscription to at least some of the presence information of theresponding entity is established for the requesting entity; receiving asubscription request, sent from the responding entity in response to thenotification, for a subscription to at least some presence informationof the requesting entity; and establishing the subscription to thepresence information of the requesting entity for the responding entitybased on the received subscription request; wherein sending the requestto the responding entity is based on the subscription established forthe responding entity.
 6. The method of claim 3 further comprisingusing, by the server, the publish-subscribe protocol for sending thedescriptor of the resource to the requesting entity in response to afetching or a polling request by the requesting entity for at least somepresence information of the responding entity.
 7. The method of claim 1wherein sending the request to the responding entity is based on asubscription established for the responding entity to at least somepresence information of the requesting entity.
 8. The method of claim 1wherein the request is sent by the server to the responding entity usingan identifier of the responding entity included in presence informationof the requesting entity.
 9. The method of claim 1 wherein the requestis sent by the server to the responding entity in response to a fetchingor a polling request by the responding entity for at least some presenceinformation of the requesting entity.
 10. The method of claim 1 whereinsending the response to the requesting entity is based on a subscriptionestablished for the requesting entity to at least some presenceinformation of the responding entity.
 11. The method of claim 1 whereinthe response is sent by the server to the requesting entity using anidentifier of the requesting entity included in presence information ofthe responding entity.
 12. The method of claim 1 wherein the response issent by the server to the requesting entity in response to a fetching ora polling request by the requesting entity for at least some presenceinformation of the responding entity.
 13. The method of claim 1 whereinthe request is included in presence information associated with therequesting entity but is not included in presence information associatedwith the responding entity and the response is included in the presenceinformation associated with the responding entity but is not included inthe presence information associated with the requesting entity.
 14. Themethod of claim 13 wherein the presence information associated with theresponding entity corresponds to presence information of the resource orpresence information of an owner of the resource.
 15. The method ofclaim 14 wherein when the presence information associated with theresponding entity corresponds to presence information of the resource,the presence information of the resource includes a link to the presenceinformation of the owner of the resource.
 16. The method of claim 13wherein the presence information associated with the requesting entitycorresponds to presence information of a second resource associated withthe requesting entity or presence information of an owner of the secondresource, the second resource being configured to form the request. 17.The method of claim 1 further comprising: authenticating, by the server,an identity of each of the requesting and responding entities; andauthorizing, by the server, a receiving by each of the entities of therequest or the response prior to sending the request or response to therespective entity.
 18. The method of claim 1 further comprising:providing, by the server, a proxy service configured for sending therequest to the responding entity through a firewall associated with theresponding entity or for sending the response to the requesting entitythrough a firewall associated with the requesting entity.
 19. The methodof claim 1 wherein the resource is at least one of a service, anapplication program, a file, and data associated with the respondingentity.
 20. The method of claim 1 wherein the descriptor is included inthe request.
 21. The method of claim 1 wherein the descriptor isincluded in each of respective presence protocol commands used inreceiving the request from the requesting entity and in sending therequest to the responding entity.
 22. The method of claim 1 furthercomprising using, by the server, the publish-subscribe protocol forreceiving from the responding entity a second descriptor of a secondresource associated with a second responding entity and a second requestrelated to the second resource, and for sending the second descriptorand the second request to the second responding entity, wherein thesecond request is related to the response replying to the request fromthe requesting entity.
 23. A method for providing a generalrequest/response protocol, the method comprising: receiving, by theserver from a requesting entity, a descriptor of a resource associatedwith a responding entity and a request related to the resource; using,by the server, the descriptor to update the presence information of theresponding entity to include the request; receiving, by the server, thepresence information from the responding entity including a responsereplying to the request; and sending, by the server, the response to therequesting entity.
 24. A method for providing a general request/responseprotocol, the method comprising: using a publish-subscribe protocol for:sending a descriptor of a resource and a request related to the resourceto a server; and receiving via the server a response replying to therequest.
 25. The method of claim 24 further comprising using thepublish-subscribe protocol for receiving the descriptor of the resourcefrom the server.
 26. A computer readable medium containing a datastructure for use with a publish-subscribe protocol in providing ageneral request/response protocol, the data structure comprising: aresource data object including an element for storing a descriptor of aresource associated with a responding entity; a request data objectincluding an element for storing a request from a requesting entityrelated to the resource; and a response data object including an elementfor storing a response from the responding entity replying to therequest.
 27. The computer readable medium of claim 26, wherein therequest data object includes an element for storing the descriptor ofthe resource associated with the responding entity.
 28. The computerreadable medium of claim 26, wherein the resource data object includesat least one element for storing information describing requestssupported by the resource and information describing responses forreplying to the supported requests.
 29. The computer readable medium ofclaim 26, wherein the request data object includes an element forstoring an identifier of the responding entity.
 30. The computerreadable medium of claim 26, wherein the response data object includesan element for storing an identifier of the requesting entity.
 31. Thecomputer readable medium of claim 26, wherein the request and theresponse each include an XML-based message formed in the structure of aSOAP message.
 32. The computer readable medium of claim 26, wherein theresource and response data objects are included in a presence tupleassociated with the resource or an owner of the resource.
 33. Thecomputer readable medium of claim 32, wherein when the resource andresponse data objects are included in a presence tuple associated withthe resource, the presence tuple associated with the resource includes adata object linking the presence tuple associated with the resource to apresence tuple associated with the owner of the resource.
 34. Thecomputer readable medium of claim 26, wherein the request data object isincluded in a presence tuple associated with the resource or a principalassociated with the requesting entity.
 35. The computer readable mediumof claim 34, wherein when the request data object is included in apresence tuple associated with the resource, the presence tupleassociated with the resource includes a data object linking the presencetuple associated with the resource to a presence tuple associated withthe principal associated with the requesting entity.
 36. A system forproviding a general request/response protocol, the system comprising: aserver configured to receive, store, and distribute information using apublish-subscribe protocol; a responding device configured to exchangeinformation with the server using the publish-subscribe protocol, theresponding device including: access to at least one resource; aresponding watcher component configured to receive, via the server usingthe publish-subscribe protocol, a descriptor of the resource and arequest related to the resource; and a responding presentity componentconfigured to send, using the publish-subscribe protocol, a response tothe server replying to the request; and a requesting device configuredto exchange information with the server using the publish-subscribeprotocol, the requesting device including: a requesting presentitycomponent configured to send the descriptor and the request related tothe resource to the server using the publish-subscribe protocol; and arequesting watcher component configured to receive, via the server usingthe publish-subscribe protocol, the response replying to the request.37. The system of claim 36, wherein the responding presentity componentis further configured to send the descriptor of the resource to theserver using the publish-subscribe protocol, and the requesting watchercomponent is further configured to receive the descriptor of theresource from the server using the publish-subscribe protocol.
 38. Thesystem of claim 37, wherein the responding device includes a respondinguser agent component coupled to the resource and the respondingpresentity and watcher components, the responding user agent componentconfigured to facilitate a sending of the descriptor of the resource bythe responding presentity component using the publish-subscribeprotocol, a processing by the resource of the request received by theresponding watcher component, and a sending of the response by theresponding presentity component using the publish-subscribe protocol.39. The system of claim 37, wherein the requesting device includes arequesting user agent component coupled to the requesting presentity andwatcher components, the requesting user agent configured to facilitate apresentation of the descriptor received by the requesting watchercomponent, a sending of the request by the requesting presentitycomponent, and a presentation of the response received by the requestingwatcher component.
 40. The system of claim 36, wherein the serverincludes a proxy service configured to send the request, using thepublish-subscribe protocol, to the responding watcher component througha firewall associated with the responding device or to send theresponse, using the publish-subscribe protocol, to the requestingwatcher component through a firewall associated with the requestingdevice.
 41. The system of claim 36, wherein the server includes anaccount service configured to authenticate an identity of each of therequesting and responding devices and to authorize a receiving by eachof the devices of the request or response prior to sending the requestor response to the respective device.
 42. The system of claim 41,comprising a database coupled to the account service including rosterand/or privacy list information used by the account service to authorizethe receiving by each of the devices of the request or response.
 43. Acomputer readable medium containing a computer program for providing ageneral request/response protocol, the computer program comprisingexecutable instructions for: receiving, by a server from a requestingentity using a publish-subscribe protocol, a descriptor of a resourceassociated with a responding entity and a request related to theresource; sending, by the server using the publish-subscribe protocol,the descriptor and the request to the responding entity; receiving, bythe server using the publish-subscribe protocol, a response from theresponding entity replying to the request; and sending, by the serverusing the publish-subscribe protocol, the response to the requestingentity.
 44. The computer readable medium of claim 43, wherein thecomputer program comprises executable instructions for using thepublish-subscribe protocol for receiving the descriptor of the resourcefrom the responding entity and for sending the descriptor of theresource to the requesting entity.